10/31/2003 13:50 FAI 2037875818 DeLio&Peterson ® 008 



REMARKS 

j Applicants appreciate the thoroughness with which the Examiner has examined 

I the above-identified application. Reconsideration is requested in view of the 

1 

! amendments above and the remarks below. 

| Applicants have amended claim 9 in response to the Examiner's rejection 

j thereof under 35 USC § 112, 12. 

! Claims 1-5, 7-9 and 11-15 stand rejected under 35 USC § 103(a) as being 

obvious from Achenson et al. U.S. Patent No. 6,477,586 in view of LiVecchi U.S. 
! Patent No. 6,427,161. Applicants respectfully traverse this rejection and request 
j reconsideration. 
! Claims 1 and 1 1 

Claims 1 and 11 recite a method of parallel processing utilizing two threads 
which each represent an independent flow of control managed by separate program 
structures. The first thread has two states: 1 ) processing work for the program structure, 
' and 2) undispatched awaiting work to process. The method involves using the second 
. thread to prepare work for the first thread to process and placing the work in a queue. 
: If the first thread is awaiting work to process when the work is placed in the queue, the 
first thread is dispatched and processes the work in the queue. If the first thread is 
processing other work when the second thread place the work in the queue, the first 
; thread completes processing of the other work then accesses the work and processes it 
from the queue. 

j As recited in the specification at pages 19-21, this aspect of the invention allows 

i 

! the first thread to be treated as a data object by the software. This first thread has a 
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second thread, or launcher, waiting on it. The first thread data object can b e passed 
around and incorporated into the data structures of a program, as can any traditional 
data object. When desired, the software program assigns particular work to the first 
thread data object. The second thread places the work in the queue, and the first 
thread then wakes up and does. After performing work, the first thread then again waits 
for more work, which may be assigned from any section of the application, at any 
desired time. If the second thread prepares additional work while the first thread is 
busy, the work remains in the queue until performed by the first thread. The first thread 
may be reused as desired by the program structure and only destroyed after it 

completes a desired amount of work. 

The hypothetical combinations of Achenson and UVecchi as cited does not 
present a prima facie case of obviousness to one of ordinary skill in the art. Achenson 
discloses a multi threaded, multi processed distributed system in which different 
processes use a dispatcher thread for passing a remote call procedure (RCP) message to 
an appropriate available thread from a pool of worker threads within the process, to 
permit the RCP message to be processed. As the Examiner has recognized, Achenson 
discloses nothing about a thread having two states, and using a second thread to 
prepare work and place it in a queue for processing by the first thread when it is 
completed processing any other work. 

The Examiner cites the LiVecchi patent for this disclosure. However, LiVecchi at 
column 3, lines 15-31 describes one implementation where a separate dispatcher 
thread keeps trade of the status of each worker thread and, only when the worker 
thread is in an idle state and has no work currently assigned to it, will the dispatcher 
thread assign an incoming request to that worker thread- As LiVecchi recognizes, "the 
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dispatcher thread may become a bottleneck that prevents worker threads from being 
scheduled fast enough to keep all of the processors busy." LiVecchi, column 3, lines 
29-31 . LiVecchi solves this bottleneck^ problem by the alternative system described 
at column 3, lines 32-50- This approach is "implemented without using a dispatcher 
thread." LiVecchi, column 3, lines 32-33 (emphasis added). Instead the worker threads 
are themselves responsible for checking a passive socket queue to determine if there 
are any connection requests, and if a request is waiting the thread removes the request 
from the queue and begins to process it. If no request is waiting, the thread then 
becomes an idle thread which then sleeps. Thus, in this latter system cited by the 
Examiner where the worker threads have two states, it is specifically disclosed that no 

dispatcher thread is utilized. 

Accordingly, LiVecchi himself teaches away from utilizing a second thread to 
prepare work for a first thread that has two states and, instead, utilizes the two-state 
thread without a second or dispatcher thread. Thus the present invention as defined by 
applicants' claim 1 is not prima facie obvious since the hypothetical combination of 
elements, chosen as a result of the hindsight benefit of reading applicants' own 
specification, does not arrive at the present invention. 
Claims 2A. 7, 8 and 12-14 

Dependent claims 2 and 12 recite that the second thread continues to place 
additional work in the queue, which is sequentially processed by the first thread as it . 
completes processing prior work. The disclosure cited in Achenson does not make up 
for the teaching in LiVecchi that a two-state thread, i.e. applicant's first thread, is not 
used with a second or dispatcher thread. Similarly, the disclosure cited in Achenson for 
applicants' claims 3 and 13 (marking the work in the queue as not complete) and 
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claims 4 and 14 work in queue is made to wait until completed work is marked 
complete) does not make up for LiVecchi's teaching away from utilizing a second 
dispatcher thread with a first two-state thread. Claim 7 combines the subject matter of 
claims 1, 2 and 3, and claim 8 recites the subject matter of claim 4, so that Achenson 
and LiVecchi do not present a prima facie case of obviousness for these claims as well. 
Claims 5, 9 and 15 

Claim 5, dependent on claim 1, claim 9, dependent on claim 7, and claim 15, 
dependent on claim 1 1 add that the first thread is reused to process other work. For 
this, the Examiner cites from LiVecchi, "as each thread completes the work requested 
has been processed, it looks on the queue for its next request" (LiVecchi column 3, 
lines 35-37). However, this aspect of the various processes disclosed therein is from 
the embodiment that is "implemented without using a dispatcher thread.' 1 LiVecchi 
column 3, lines 32-33. Accordingly, one of ordinary skill in the art would not look to 
this portion of LiVecchi in connection with applicants' claimed process using a second 
thread to provide work in a queue to a first, two-state thread. 

Claims 6. 10 and 16 

Claims 6, 10 and 16 stand rejected under 35 USC § 103(a) as being obvious 
from Achenson in view of LiVecchi in view of Voll et al U.S. Patent No. 6,170,018. 
Applicants respectfully traverse this rejection. 

Applicants* dependent claims 6, 10 and 16 recite that the program structure 
destroys the first thread after it completes a desired amount of work. Again, applicant 
submits that prima facie obviousness is not established by the combination of 
Achenson and LiVecchi for the reasons described above, and because LiVecchi's 
teaching away from the method of the present invention is not rectified by any teaching 
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in Voll. Voll describes no two-state first thread which is fed work in a queue by a 
second thread. Voll is only cited for its disclosure that a thread may be destroyed when 
processing by it completes. This disclosure does not suggest applicants' invention 
wherein the first thread repeatedly cycles between the processing work state and the 
undispatched awaiting work state. As it receives work from a queue fed by a second 
thread, after which the first thread is destroyed after It completes a desired amount of 
work. Accordingly, applicant's invention as recited in claims 6, 10 and 16 is not 
obvious from any combination of Achenson, LiVecchi and Voll. 

For the reasons given above, applicants submit that the claims of the instant 
application are in condition for allowance. Reconsideration of the rejection and 
allowance of the claims re respectfully requested. Any questions which may be 
handled by telephone should be directed to the undersigned at (203) 787-4595. 

Respectfully submitted, 




*eter WTPeterson 
Reg. No. 31,867 



DeUO & PETERSON, LLC 

121 Whitney Avenue 

New Haven, CT 06510-1241 

(203) 787-0595 

ibmf100275000amdA 
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< = c^ kcls Uycr or "SSL" typically use a differ col This dew interrupt approach lewis to the first pcrformaiKX 

^ni^cr ibfn "do^ communications without problem to be addressed by ibe present ^veimon. wh,cb wdl 

"£ rtf^^Jliaiig-), Tbc server accepts a be referred to herein a, y*****^. TlT^Zc 

S clicnl coooemionfrcm the Special r^ve socket- bef of incoming conr*Ct*>OS is less than the intmber of 

^c^jes a dcnV server socket, wbich is then assigned lO 5 threads in Ibe thread pool (ix, ibe connection load is less 

an available thread for processing than the majrimum for which the server ^ configured), too 

A number of shortcomings exist id ux cuitcdL approach to maoy threads from ibe pool arc used to service tbc w ^™- 

implementing nrrftilhfeaded server applications moping in In other words, the thread pool is being over-scheduled. This 

lb)5 environment, which result id less than optimal perfor- k;ads 10 inefficient use of resources. 

jnance Of those applications. With tbe inaeasing popularity l0 ^ foTtawmg scenario illustrates ibe overnwiiedtiliflg 
of applications such as those running on Web servers, which pr00 ] tra . Suppose all threads are blocked, waiting for con- 
may receive thousands or even millions of "hi Is" 0-C- client requests. A first request arrives. The system sebed- 
requests for proccSSiDg) per day. performance becomes a of bloctcd ihxc^ and aligns tbe 
critical concern. T*e present invention addresses these pe^ „ ^ thrcad . The thread begins process- 
formanoc concerns- 15 - ^ a second request arrives, SO the 
In^rispng . «rvec implementa*^ _a ^ scheduler «Jakes np a second blocked thread and assign* Oris 
tk«ad * typpc^y ^request to iL The second thread be^ proc^infi this 
EtSTT.T^^ Zcs, m firs, u™d ^ » ^ 
^eTn fcetaad d4>^ patching, and those threads working on, at* checks the passive socket. Find* ft ^po new 
^S^dS^Zrtu^tlcr ore referred to herein 20 con*eclion requests there, the first thread Wocte. tor two 
as "Wker tftftaV- Tbc ditcher thread keeps InCk of the requested the scheduler has awakened two threads- 
status of each worker thread, and assigns each inttwning However, il may be that thread one was nearly finished 
request to an available thread. An "available'' thread is one its first request at the time the second request arrived, 
that is ready to run, but has no work currently assigned to it. When this is the case, it would be more efficient to wail for 
A thread in Ibis stale may eqirivakntly be referred to as an 25 me ^ Ux^d to finish and find the second request when it 

C-idle thread". WbCD -omHr j^g^T^d in an idle thread, il is cJ)Cclcs ^ p^-frc socket, as opposed to awakening the 

n o! longer considered idU ^ and no further work will, be xC0C fi ihread. If the scheduler awakens a Dew thread for 

assigned to ii unfi t n^nas c o mtneicd m n i fftnt worfc regue^ tach inning request (i-C- it ovcr-scbedulcs the threads), a 

Cm" SMH maclSSSn^^atcher thread may 1 b^woe a working on a request is giiaxaniccd to find the 
bottleneck ih*t prevent* worker threads from being SCocd- w incOTjin£ connection Queue empry when il compiles its 

ulcd fast enough to keep all of ibe processors busy. current request and checks for another. The threads wfll 

["i Alternatively, a server may be implemented witho ut usin g ^refbre block after each completed request. The repealed 

a dispatcher thread- In this approach, the threads are reSpOD- plotting and unblocking operations are eipenSrvc in terms 

sible for checking the passive socket queue to delcfiniDC jf of ^ pamlenglh for servicing a request. When a 
there arc any connection requests. A^TCach QiTt&d iwusuk)h» 35 jhjead bolcks, the scheduler will save the conieit infonna- 

i lMMWmtiig^i^ l ft hai M iiijfaM"i > ni i ^tf'fl -I f W^^ thegpeBO rioo fa ^ tfjnad, and the thread will move from tbe 

&»^te» iiLJl t^ fa trrJfrB .wycstrJS. waitni& .m c, thread .; , -^y- to "bkidcefr stale. The unWocidng opera- 

^ W a W rt 4he 1 T^eSt^Ohlih e qucrov^nd *>c&wt*±vu#A&3. rcquifts ^ fairry-sigDificant overhead associated with 

^ t llX 11 Q«l^isw.in^i3K interrupt processing, 

Tfb^iJlaibiu^ 40 A fnrthcr - ^ ^ ^ ^ten,^ performance during 

VMajto^i^^feihrcad to Vail ^aptiAnMMfflrt penod ^^^^ a caused by the memory paging mecha- 

^Rim^^ -^^ ***** ^XaSd executcs.it wfll refer to sC^infonna- 

JWjKfr* awoi This^ to ^P^^ don. That inf onnation must be in memory to be processed, 

mote commoc alternative 10 J*^™^J* % ^ ff U is not already in memofy. U wfll be paged in. locally, 

driwnmlerraplS-^U^tappioac^m^ 45 fpt « n „ii be paged out to make room for the one 

idle state and wbU for a ^ystem-generated 1 n^errnpt t^l wfll ™f b p^^aoismsuse algcrithms to decide 

be invoked when work *^J^°& wbSi pa^to payout. C6tnmooly F the leasl-recently-used 

becoroe active agam. Going into the 'f^^J^^"^ _ i^cctedfor pagjng out. When over^Cheduhng 

to a^i -blockiI^^andbeh^awak C n^^ U^b^cUd Stan, ^^ c ^Tmr«4 blockV aflcr it cxeoiKS, and its pages 

(Lc. receiving the interrupt) ?s rcfened to as ^k)c*ing". 50 lberc ^ c ^0,^ The longer a thread bfocks, tbc 

In current server innricfnentahons that use cvenl-bViven mofT5 j becomes that its pages wjtD be paged onL 

mlexrupts, as each worker thread complete* its current Tbcn ^ ^ {Ja ^ d fc ^hj^ ite pag^ must be paged 

request, it checks the passive socket quetic to sec if any ^ ^ causing in be r«ged out. Tbe 

requests are waiting. When there K DO wwlmg request, tHe ^ processing caused by these paging C^jefaiirjoS reduces 

thread blocks. Any nimir^ of Oircads may be blocked ai a 55 ^ c &CKDcy of processing the meODXWg reqiteSL 

given time. When the next incoming *^J™?^ AdmtiODally, tbe operation of checking the passive 

event is generated to wake up the mmads^Each bW«d J^™£7o find it empty, is a wasted operation wmch 

worker thread receives this mlemml, so each unblocks and ^-^2™ ' ( ^ bk>Ca^threaiL 

tries to uki: ibe rc<ruesiW the o^ Only the Grrf worker further reduces the Clancy ot irx: woca^ng 

tbxead will be able to lake ihv ilK^ming request, and the 60 A second pcrfbfTOaDce probletD will be retened to bereio 

otbcES wfll again find the queue empty and return to the as the "muldole input souxec" problem. As previously Stated, 

blocked stale. However, a new API (Application Program- a server application may receive uoseenre connec^nn 

mine Interface) is under development to change this requests on ODC passive socket, and secure connection 

approach to interrupt generation. The API is referred to requests on a second passive *ockei_ TJus will bethc case. 

Win as w accepL_and ^reoeive^ According, lo tbe arxcpt__ ^ for enmpk, m on-fine shopping appbeanons. The chcnl 

^L_receive APJ, when an nX»roing request arrives, an shopper may request to display available V™**** an 

interrupt wfll be generated only to a single blocked thread. on-line catalog, eventually selecting some products to be 
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